Skip to content

Limit deploying and undeploying channels to the requested IDs (fixes #456) - #567

Open
iacsha wants to merge 1 commit into
OpenIntegrationEngine:mainfrom
iacsha:fix/456-channel-statistics-race
Open

iacsha wants to merge 1 commit into
OpenIntegrationEngine:mainfrom
iacsha:fix/456-channel-statistics-race

Conversation

@iacsha

@iacsha iacsha commented Nov 7, 2026

Copy link
Copy Markdown

Fixes #456.

Cause. DonkeyEngineController.getDashboardChannels(channelIds) filters donkey.getDeployedChannels() by the requested IDs, but then adds every channel in deployingChannels and undeployingChannels without that filter. So while channel B is mid-deploy or mid-undeploy, a request scoped to {A} also gets B. ChannelStatisticsServlet.getStatistics(channelId) returns channelStatisticsList.get(0), and when A is not deployed, B (a dashboard channel) is listed before undeployed A, so the response describes B. The same helper feeds getChannelStatusList, so per-channel dashboard status was affected too.

Fix. Apply the requested-ID filter to the deploying and undeploying sets as well. Unfiltered requests (no IDs) behave exactly as before, and a deployed channel still wins over a transitional entry with the same ID. The collection logic moved into a package-private static getDashboardChannels(deployed, deploying, undeploying, channelIds) so it can be unit tested without starting the engine; the instance method delegates to it.

Tests. New DonkeyEngineControllerDashboardChannelsTest (5 cases). With the filter removed, 3 of them fail; with the fix, all pass. Full :server:test passes (841 tests, 0 failures).

End-to-end repro (the issue's steps, on images built from main and from this branch, fresh appdata each): two VM-reader channels A and B, A left undeployed; one loop deploys B, sends a message, and undeploys B; three loops poll GET /api/channels/{A}/statistics for 90 seconds.

Build Deploy cycles Polls Responses describing B
main 539 6151 837
this branch 560 6404 0

With A deployed, main happened not to show it in my runs because HashMap order put A first, which is luck rather than correctness; the fix doesn't depend on ordering.

…penIntegrationEngine#456)

getDashboardChannels filtered deployed channels by the requested channel IDs but added every deploying and undeploying channel unfiltered. A request for channel A made while channel B was mid-deploy or mid-undeploy therefore included B, and GET /channels/{A}/statistics, which returns the first entry, could describe B. Apply the same filter to the transitional sets. The collection logic moves into a package-private static helper so it can be unit tested.

Signed-off-by: iacsha <122627209+iacsha@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] GET /channels/{channelId}/statistics returns the counters of an unrelated channels

1 participant